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ABSTRACT 

The  C2  Workstation  (C2WS),  developed  by  the  Royal  Netherlands  Army  (RNLA),  is  a  configurable 
application  platform  and  information  system  that  provides  generic  functionality  to  support  the  Command 
and  Control  process.  The  C2WS  supports  the  users  in  building  and  maintaining  a  Common  Operational 
Picture  (COP)  in  order  to  enhance  the  Situational  Awareness.  The  C2WS  has  conversion  modules  for 
ATCCIS  and  RNLA  legacy  systems  e.g.  the  Integrated  Staff  Information  System  ‘ISIS’  and  the  Battlefield 
Management  System  BMS. 

TNO-FEL  has  recognised  an  opportunity  to  support  the  C2WS  assessment  activities  by  ongoing 
experimental  studies  on  coupling  of  simulation  tools  with  the  C2  architecture.  The  simulators  will  be  used 
to  provide  stimuli  (e.g.  unit  detection  or  movement)  to  the  C2WS  and  thus  objectively  assess  the 
C2-systems  involved  and  facilitate  training  and  education  of  the  users  of  these  C2-systems. 

Our  architectural  approach  is  to  provide  a  software  gateway  to  the  modern  High  Level  Architecture 
(HLA)  simulation  standard.  The  link  to  HLA  provides  the  possibility  to  connect  many  modern  simulation 
components  to  the  C2WS  architecture.  The  HLA  development  process  provides  a  generic  approach  to 
simulation  interoperability  for  the  C2WS.  As  a  first  demonstrator  of  interoperability  between  the  C2WS 
and  an  HLA  Simulation  system,  a  Decision  Support  System  (DSS)  has  been  selected.  This  DSS 
concentrates  on  Course  of  Action  (CO A)  analysis.  The  COP  defined  in  the  C2WS  is  copied  to  a  planning 
overlay  on  the  C2WS  and  transferred  to  the  DSS.  The  DSS  evaluates  this  input  using  simulation  and  the 
results  from  the  analysis  are  routed  back  to  the  C2WS  in  the  form  of  a  new  planning  overlay.  This  overlay 
can  then  be  evaluated  by  the  C2  operator. 

Future  applications  of  the  addition  of  Simulation  components  to  the  C2WS  will  be  a  more  extended 
Decision  Support  functionality  (e.g.  route  planning,  fire  support  planning,  etc.)  and  the  use  of  simulators 
for  C2  training  of  commanders. 

This  paper  presents  an  overview  of  the  architecture  and  the  demonstrator  under  development.  Application 
areas:  (1)  Test  and  assessment  (as  part  of  the  Acquisition  process),  (2)  Training  &  Instruction, 
(3)  Operations  Support. 

Key  Words:  C2  -  Simulation  Interoperability,  Simulator  Architecture,  HLA  Middleware. 
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ORGANIZATION 


1.0  INTRODUCTION 

This  paper  addresses  the  approach  used  by  TNO-FEL  to  develop  and  demonstrate  concepts  for 
interoperability  between  C2  system  and  Simulations.  Simulation  interoperability  for  C2  systems  enables 
applications  in  training  of  army  staff  officers,  operations  support  and  procurement,  assessment  and 
evaluation  of  C2  systems.  The  project  is  aimed  specifically  at  the  C2  Workstation  (C2WS),  a  new  system 
for  the  Royal  Netherlands  Army  (RNLA),  which  is  in  an  early  stage  of  its  development. 

The  requirements  for  the  design  of  the  C2-Simulation  interoperability  are:  flexibility,  scaleability, 
robustness  and  compliancy  to  international  standards. 

As  a  first  demonstrator  of  interoperability  between  the  C2WS  and  an  HLA  (High  Level  Architecture) 
based  Simulation  system,  a  Decision  Support  System  (DSS)  was  chosen,  which  concentrates  on  Course 
of  Action  (COA)  analysis.  The  DSS  analyses  plans,  prepared  on  the  C2WS,  using  simulation  and 
results  from  the  analysis  are  routed  back  to  the  C2WS  as  a  new  planning  overlay,  for  evaluation  by  the 
C2  operator. 

The  next  section  addresses  the  need  for  interoperability  and  the  general  concept  of  coupling  C2  systems  to 
Simulations.  Section  3  explains  the  interoperability  approach  followed  for  the  C2WS;  section  4  discusses 
the  High  Level  Architecture  which  has  become  the  interoperability  standard  used  in  the  Simulation 
domain.  The  remaining  sections  discuss  the  system  architecture,  implementation  issues  and  some 
preliminary  results  and  conclusions  of  this  project. 


2.0  LINKING  C2  SYSTEMS  TO  SIMULATION  MODELS 

Linking  C2  systems  to  Simulation  systems  has  many  potential  applications: 

•  Simulation  systems  can  stimulate  the  C2  system  by  providing  data  that  simulates  the  ‘real-world’. 
This  information  will  now  appear  to  have  been  received  from  peer  C2  systems.  In  this  way 
a  simulated  COP  (Common  Operational  Picture)  is  created  that  is  based  on  a  simulation  scenario. 
Applications  of  this  technique  are:  assessment  of  C2  systems  (performance,  user  interface  etc.), 
assessment  of  C2  operator  capabilities  or  even  training  of  C2  operators. 

•  The  simulation  can  provide  the  C2  operator  with  operational  decision  support  by  executing 
‘what-if  scenarios.  These  scenario’s  can  support  the  operator  in  his  decision  making  process 
(e.g.  mission  planning  or  assessment  of  alternative  COA’s). 

•  New  or  experimental  parts  for  an  existing  C2  system  can  be  evaluated  before  purchase  or  even 
before  development  of  the  component  by  replacing  an  existing  component  of  the  C2  system  with 
an  embedded  simulation.  Simulation  systems  can  be  ‘initialised’  from  the  existing  COP  in  the 
C2  system  and  a  simulation  run  can  be  started  based  on  this  information,  assessing  what-if 
scenarios. 

The  advantage  of  using  simulations  as  a  tool  for  stimulation  of  C2  systems,  as  apposed  to  ‘role  players’, 
is  that  the  simulation  has  a  consistent,  controlled  and  reproducible  behaviour,  which  allows  objective 
assessment  of  system  and/or  operator  performance.  TNO-FEL  has  recognised  an  opportunity  to  support 
the  C2WS  assessment  activities  by  ongoing  experimental  studies  on  coupling  of  our  simulation  tools 
with  this  C2  architecture.  The  aim  of  the  research  is  to  develop  a  flexible  and  future-proof  approach 
to  the  C2-Simulation  interoperability  problem.  First  we  need  to  clarify  what  we  really  mean  by 
‘interoperability’. 

Interoperability  is  the  degree  to  which  entities  are  able  to  co-operate  in  achieving  a  common  goal. 
There  are  many  interpretations  of  the  concept  of  interoperability  between  computer  systems.  It  varies  from 


A7  -2 


RTO-MP-117 


Simulation  Interoperability  for  the  new  RNLA  C2  Workstation 


having  a  network  connection  and  being  able  to  transfer  files  (e.g.  email)  to  using  exactly  the  same 
applications  at  all  systems  and  completely  sharing  the  information  they  process.  A  commonly  used  form 
of  interoperability  is  ‘information  interoperability’,  because  it  offers  optimal  connectivity  between 
systems,  while  preserving  maximum  independence.  Information  interoperability  is  defined  as  the  ability  of 
systems  to  automatically  exchange  and  interpret  information  that  is  common  to  those  systems  [Ref  1]. 

In  this  paper  we  focus  on  information  interoperability  that  is  achieved  by  the  automated  exchange  and 
interpretation  of  structured  information  between  systems.  With  minimum  user  intervention,  C2  systems 
and  Simulation  systems  must  be  able  to  automatically  interchange  certain  information  and  utilise  that  for 
further  processing.  This  means  that  the  information  must  be  structured,  because  this  enables  functionality 
such  as  distribution  by  subscription  on  certain  topics,  presentation  of  information  and  filtering  by  specific 
selection  criteria.  The  emphasis  here  lies  on  the  exchange  of  information  (rather  than  ‘free  format’ 
databits),  preserving  its  meaning,  integrity  and  context.  Structured  information  is  described  formally  by  a 
‘Datamodel  ’.  The  datamodel  thus  represents  the  foundation  for  information  interoperability. 

In  the  most  common  case  where  many  systems  have  to  exchange  information,  standardisation  of  a 
common  ‘interface’  is  a  key  factor  to  achieve  information  interoperability.  Otherwise,  dedicated  interfaces 
are  needed  between  every  pair  of  interconnected  systems,  leading  to  an  exponential  grow  of  the  number  of 
interfaces  required.  Preferably  the  exchange  should  not  depend  on  proprietary  products,  such  as  database 
management  systems  and  communication  systems.  The  key  notion  for  information  interoperability  is 
standardisation.  By  having  common  agreements  on  which  information  is  exchanged,  in  what  format, 
and  under  what  conditions,  it  becomes  easier  to  allow  systems  of  different  types  to  interoperate. 


3.0  C2WS 

The  C2WS  is  a  configurable  application  platform  and  information  system  that  provides  generic 
functionality  to  support  the  Command  and  Control  process.  The  C2WS  supports  the  users  in  building  and 
maintaining  a  COP  in  order  to  enhance  the  Situational  Awareness. 

The  C2WS  is  being  developed  at  the  RNLA  C2  Support  Centre,  with  cooperation  of  TNO-FEL. 
The  C2WS  system  architecture  comprises  three  layers  whose  basic  functionality  can  be  segmented  into: 
presentation  services,  business  services,  and  data  services  [Ref.  2], 

The  presentation  services  layer  is  responsible  for  gathering  information  from  the  user  and  presenting 
information  to  the  user  using  the  services  of  the  business  services  layer. 

The  business  services  layer  is  responsible  for  end-to-end  business  transactions  such  as  maintaining  roles, 
contexts  and  business  objects  and  the  logic  that  applies  within  these  concepts. 

The  data  services  layer  is  responsible  for  storage,  retrieval,  maintenance  and  integrity  of  data.  The  data 
services  layer  is  also  in  charge  of  publishing  as  well  as  subscribing  and  listening  to  data  on  the  network. 

The  information  exchange  in  the  C2WS  environment  is  based  on  commercial  of  the  shelf 
publish/subscribe  services  and  a  tailored  information  exchange  language  [Ref.  3].  The  information 
exchange  language  is  based  on  the  RNLA  C3I  Architecture  (C3IA)  Information  Model  (C3IA-IM) 
for  C2  applications  within  the  RNLA.  C3IA  is  more  generic  than  the  fixed  set  of  descriptive  attributes  of 
ATCCIS. 

The  C2WS  has  conversion  modules  for  RNLA  legacy  systems  such  as  the  Integrated  Staff  Information 
System  ‘ISIS’  and  the  Battlefield  Management  System  ‘BMS’.  A  translator  service  shall  be  made 
available  for  translating  C3I  information  to  proprietary  systems  such  as  the  German  C2  system  ‘HEROS’. 
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At  the  time  of  writing,  the  C2WS  supports  GIS  functionality  for  placing  units  and  lines/areas  on  the  map. 
The  network  functionality  is  partly  implemented,  for  example  updates  of  the  COP  for  a  certain  ‘context’ 
can  be  exchanged  between  different  C2WSs.  However  a  means  for  a  new  C2WS  to  hook  into  the  network 
and  receive  the  full  current  COP  has  not  yet  been  implemented. 
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Figure  1:  The  RNLA  C2  Workstation  (Pre-Released  Prototype,  Sept  2001). 


4.0  HLA 

The  High  Level  Architecture  (HLA)  is  an  architecture  for  reuse  and  interoperation  of  simulations 
[Ref.  4,  5,  6].  The  HLA  is  based  on  the  premise  that  no  single  simulation  can  satisfy  the  requirements  of 
all  uses  and  users.  An  individual  simulation  or  set  of  simulations  developed  for  one  purpose  can  be  applied 
to  another  application  under  the  HLA  concept  of  the  Federation:  a  composable  set  of  interacting 
simulations  [See  Figure  2], 
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Figure  2:  HLA  Federation. 


The  intent  of  the  HLA  is  to  provide  a  structure  that  will  support  reuse  of  capabilities  available  in  different 
simulations,  ultimately  reducing  the  cost  and  time  required  to  create  a  synthetic  environment  for  a  new 
purpose  and  providing  developers  the  option  of  different  implementations  within  the  framework  of  the 
HLA. 

The  HLA  provides  the  specification  of  a  common  technical  architecture  for  use  across  all  classes 
of  simulations:  (a)  Virtual:  “Real  people  operating  simulated  equipment”,  (b)  Constructive: 
“Simulated  people  operating  simulated  equipment”  and  (c)  Live:  “Real  people  operating  real  equipment  on 
an  instrumented  training  range”.  HLA  provides  the  structural  basis  for  simulation  interoperability. 
The  baseline  definition  of  the  HLA  includes  the  HLA  Rules,  the  HLA  Interface  Specification  (IFSpec), 
and  the  HLA  Object  Model  Template  (OMT).  The  HLA  interface  specification  defines  many  services  that 
HLA  provides  to  the  application.  These  services  include  Object  Management  (publish/subscribe) 
and  Time  Management  (i.e.  synchronisation  between  distributed  applications).  The  Federation  Object 
Model  (FOM)  is  the  datamodel  of  the  HLA  Federation.  The  OMT  is  the  standard  format  that  is  used  in 
HLA  documentation. 

The  HLA  does  not  prescribe  a  specific  implementation,  nor  does  it  mandate  the  use  of  any  particular 
software  or  programming  language.  Over  time,  as  technology  advances  become  available,  new  and 
different  implementations  will  be  possible  within  the  framework  of  the  HLA.  In  February  1998,  version 
1.3  of  the  HLA  specification  was  adopted  by  the  US  Defense  Modelling  and  Simulation  Office  (DMSO) 
and  in  September  2000  it  has  been  accepted  as  IEEE  Standard  1516  for  simulation  interoperability. 
The  HLA  is  a  standard  for  use  in  the  US  Department  of  Defense  and  within  NATO  (NATO  MSMP  1998). 
Development  of  a  generic  coupling  between  C2  systems  and  HLA  thus  provides  the  possibility  to  connect 
modem  simulation  components  to  the  C2  environment. 

One  of  the  main  components  of  HLA  is  the  Run-Time  Infrastructure  (RTI).  The  RTI  implements  the  HLA 
IFSpec  and  allows  the  user  to  invoke  the  RTI  services  to  support  run-time  interactions  among  Federates 
and  to  respond  to  requests  from  the  RTI.  This  interface  is  implementation  independent  and  is  independent 
of  the  specific  object  models  and  data  exchange  requirements  of  any  Federation.  At  TNO-FEL  we 
developed  an  HLA  based  middleware  layer,  called  the  Runtime  Communication  Infrastructure  (RCI) 
[Ref.  7]  which  supports  HLA.  The  RCI  shields  the  developer  from  many  intricate  details  concerning  the 
usage  of  the  HLA-RTI,  including  Data  Distribution  Management  (DDM)  [Ref.  4,  5,  6],  when  developing 
either  a  Component  or  a  Federate.  The  RCI  includes  a  C++  code-generator  to  translate  the  required 
HLA-OMT  descriptions  into  easily  accessible  object-oriented  classes  The  C2-Sim  coupling  approach 
described  here  is  based  on  our  RCI  concept. 
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5.0  C2WS-BRIDGE  FEDERATION 

The  first  demonstration  target  of  our  project  was  to  achieve  interoperability  between  the  C2WS  and  an 
HLA  Simulation  system.  More  specifically,  the  use  of  simulation  as  a  Decision  Support  System  (DSS), 
which  concentrates  on  Course  of  Action  (COA)  analysis.  The  COP  defined  in  the  C2WS  is  copied  to  a 
planning  overlay  on  the  C2WS  and  transferred  to  the  DSS.  The  DSS  analyses  this  input  through 
simulation  and  results  from  the  analysis  are  routed  back  to  the  C2WS  as  a  new  planning  overlay  available 
for  evaluation  by  the  C2  operator.  The  Federation  that  was  developed  for  this  demonstration  is  named  the 
‘C2WS-Bridge  Federation’  and  consists  of  the  following  Federates: 

•  FedMan,  this  (optional)  Federate  was  developed  by  TNO  and  is  used  as  Federation  Manager. 
It  has  online  capabilities  to  initialise,  monitor,  start,  stop,  pause  and  abort  the  whole  system. 
The  Federation  Manager  also  has  the  ability  to  monitor  the  activities  of  all  participants  and 
systems  and  take  appropriate  (planned  &  unplanned)  action,  to  ensure  a  successful  completion  of 
the  exercise; 

•  Decision  Support  Federate.  This  Federate  is  based  on  the  ‘Bridge’  constructive  combat  simulation 
model  developed  by  TNO-FEL  for  the  RNLA.  It  is  responsible  for  the  simulation  of  ground  and 
air  brigade/division  mobile  operations.  The  Federate  was  modified  to  handle  the  input  from  the 
C2WS  and  deal  with  the  required  Objects  and  Interactions. 


Figure  3:  The  DSS  Tool  Bridge  (TNO-FEL  Prototype). 

•  Stealth  Federate,  a  3D  viewer  into  the  virtual  environment.  This  (optional)  Federate  is  based 
on  the  available  TNO-FEL  Stealth  from  TNO-FEL’s  Electronic  Battlespace  Facility  (EBF). 
The  Stealth  is  interoperable  with  the  Federation  through  a  ‘DIS/HLA  Gateway’  and  thus 
demonstrates  our  capability  to  deal  with  ‘legacy’  DIS  Federates; 

•  C2WS  Federate,  one  or  more  (unmodified)  C2WS  applications  (C2  GIS)  manned  by  their  regular 
RNLA  operators.  See  figure  1. 
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The  C2WS-Bridge  Federation  was  able  to  adopt  the  DiMuNDS  2000  FOM  [Ref.  8]  (see  next  section). 


Figure  4:  Tailor  Made  Connections.  Figure  5:  Connections  using  an  Intermediate  Layer. 

(Not  Fully  Interconnected)  (Fully  Interconnected) 


6.0  BRIDGING  THE  GAP 

Previous  attempts  to  couple  C2  systems  with  simulations  were  often  ad-hoc  and  resulted  in  tailor-made 
connections  for  every  specific  combination  of  C2  systems  and  simulation  models.  When  one  of  the 
systems  needs  to  be  connected  to  another  system  or  simulation,  a  new  connection  needs  to  be  developed. 
This  approach  means  a  lot  of  work  for  both  the  C2-System  and  the  simulation  model,  see  Figure  4. 

A  more  flexible  approach  is  the  use  of  an  intermediate  layer  as  show  in  Figure  5. 

Once  a  system  or  simulation  has  a  (tailor  made)  adaptor  for  the  intermediate  layer,  the  system  can  be 
connected  to  other  systems  or  simulations  without  any  additional  work  on  the  other  sides. 

The  approach  that  was  followed  to  achieve  C2WS-Simulation  interoperability  resembles  the  ‘intermediate 
layer’  solution,  however  with  an  important  difference:  both  the  C2WS  systems  and  the  Simulation  systems 
already  support  interoperability  within  their  own  domain. 

The  C2-System  uses  a  commercial  of  the  shelf  product,  TIB/Rendezvous  (TIB/RV)  from  Tibco, 
to  exchange  information.  The  simulation  systems  use  the  HLA  interoperability  standard.  A  ‘gateway’ 
connects  TIB/RV  on  one  side  to  HLA  on  the  other  side  (see  Figure  6). 


Figure  6:  C2-Simulation  Datamodel  Interoperabilty. 


RTO-MP-117 


A7-7 


Simulation  Interoperability  for  the  new  RNLA  C2  Workstation 


ORGANIZATION 


In  addition  to  interoperability  at  the  technical  level  (protocols,  networks  etc),  we  also  need  to  develop  the 
information  interoperability:  bring  the  Datamodels  inline  and  provide  a  two-way  mapping  for  all  relevant 
attributes  (see  Figure  6).  HLA  systems  are  connected  to  each  other  in  a  Federation  and  define  their 
communication  via  a  Federation  Object  Model  (FOM).  The  FOM  has  to  be  agreed  upon  between  the 
systems  that  need  to  be  connected.  For  the  C2-Simulation  system  a  C2WS-Bridge  Federation  has  been 
designed  together  with  an  initial  FOM  based  upon  the  FOM  used  previously  in  the  NATO  DIMUNDS 
2000  demonstration  [Ref.  8]. 

This  FOM  describes  four  generic  objects  which  are: 

•  Weather, 

•  Stationary, 

•  Mobile  and 

•  StationaryMultiLocation. 

The  information  that  is  exchanged  via  the  FOM  consists  amongst  other  things  of  the  position  of  the  object 
and  depending  on  the  object  information,  for  example  status  and  speed.  It  is  often  impossible  to  directly 
map  the  information  exchanged  between  C2-systems  onto  the  FOM. 

Table  1:  Schematic  DiMuNDS  2000  FOM  Datamodel. 


Object 

Specialisation 

Specialisation 

Specialisation 

Weather 

Stationary 

Seaport 

Pumping  station 

C2-centre 

Corridor 

Airbase 

Depot  radarsite 

Bridge 

CivilBridge 

Combatbridge 

StationaryMulti 

Location 

Special  area 

Minefield 

Non  lethal 

obstacle 

Mobile 

Sea 

Surface 

Sub-surface 

Air 

Cruise  missile 

Air  mission 

Fixed-wing 

Helikopter 

Ground 

Non-combat 

Combat  service 
support 

Engineer 

Sensor 

Fire-support 

Manouvre 

Airdefence 

HiMad 

ShoRad 
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In  most  cases  it  is  necessary  to  combine  information  from  the  C2-system  in  order  to  get  it  mapped  onto  the 
FOM  and  vice  versa.  In  an  initial  quick  research  the  following  fields  were  identified  for  a  unit  message 
that  need  adaptation  before  they  can  be  mapped  on  either  the  FOM  or  on  the  C2  information. 

Table  2:  Data  Mapping  Fields  (not  exhaustive) 


FOM 

C2WS 

ObjName 

Name 

PartyNumber 

Nationality 

Velocity 

SpeedQty 

Position 

Position 

Front 

BearingAngle 

A  name  in  the  FOM  needed  to  be  restricted  to  10  characters,  the  FOM  only  knows  of  four  different  parties 
while  the  C2WS  allows  many  more  different  nationalities,  and  the  location  of  a  unit  in  the  UTM  system 
of  the  C2WS  needed  to  be  translated  into  the  relative  map  coordinates  used  by  the  FOM.  Specific 
conversions  and  layout  issues  had  to  be  resolved  and  implemented  to  realise  any  coupling  between  the  two 
domains. 


7.0  TIBCO-HLA  GATEWAY 

A  TIBCO/HLA  Gateway  was  developed  for  the  purpose  of  incorporating  a  C2WS  in  the  Federation. 

The  Gateway  (see  Figure  7)  was  implemented  using  two  processes,  one  attached  to  the  RCI 
(HLA  middleware)  and  the  other  attached  to  TIB/RV  (main  component  of  the  C2WS  interoperability 
middleware  from  Tibco).  Both  sides  use  a  broadcast  (publish/subscribe)  method  to  distribute  data  on  the 
network.  TIB/RV  listens  to  messages  on  the  network  and  places  an  image  of  the  object/interaction  data 
concerning  the  C2WS  entities  (to  which  a  subscription  was  issued  by  the  Gateway)  in  shared  memory.  The 
RCI  process  subsequently  reads  this  data  from  shared  memory  and  maps  it  onto  the  HLA- SOM  via  the 
RCI  middleware.  The  same  holds  for  communicating  data  from  the  HLA  Federation  to  the  C2WS  world 
where  TIB/RV  publishes  the  object/interaction  data  received  from  the  Federates  in  the  Federation. 


Figure  7:  C2WS  Federation  with  TIBCO/HLA  Gateway. 
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The  Federation  was  developed  by  (loosely)  following  the  Federation  Development  and  Execution  Process 
(FEDEP)  [Ref.  6]. 

The  objective  of  the  Federation  was  defined  as: 

•  Demonstrate  interoperability  between  constructive  (wargame)  simulations  and  C2  systems  using 
FILA.  The  focus  of  the  scenario  and  the  simulation  application  is  on  features  that  are  important  for 
Decision  Support. 

The  following  documentation  is  typically  produced  in  the  FEDEP: 

•  Federation  Objectives,  Requirements  and  Conceptual  Model.  This  provides  details  for  FEDEP 
steps  1  ( Define  federation  objectives)  and  2  ( Perform  conceptual  analysis).  The  document 
describes  the  statement  of  ‘Federation  Objectives’,  ‘Scenario  Requirements’,  ‘Conceptual  Model’ 
and  ‘Federation  Requirements’.  Federation  requirements  described  in  the  document  serve  as  a 
vehicle  for  transforming  objectives  into  functional  and  behavioural  capabilities,  and  provide  a 
crucial  trace-ability  link  between  the  Federation  objectives  and  the  design  implementation. 
The  requirements  are  derived  from  the  specification  of  the  Federation  Objectives  and  the 
high-level  description  of  the  Scenario. 

•  Federation  Scenario  Document,  this  document  describes  the  scenario  in  full  detail,  the  geographic 
location  of  interest,  the  nature  and  size  of  forces,  in  our  total  scenario  represented  by  about 
60  computer  generated  forces  (CGF)  units,  the  initial  positions  and  the  occurring  events. 

•  Federation  Design  and  Development  Document,  this  document  provides  details  for  FEDEP  steps 
3  ( Design  Federation)  and  4  ( Develop  Federation).  This  phase  of  the  FEDEP  is  concerned 
with  the  detailed  design  of  the  Federation  (including  mapping  of  Federation  Objectives  and 
Requirements  to  Federates),  the  selection  of  and  modification  of  existing  Federates  and  the 
development  of  new  Federates.  The  document  describes  the  results  of  the  selection  process, 
the  definition  and  development  of  their  interactions  (laid  down  in  the  FOM)  and  mapping  of 
Federation  objects/functionality  on  Federates.  The  document  also  details  Federation  agreements 
(e.g.  Operating  Systems,  Tool  versions,  and  co-ordinate  systems). 

•  Documentation  supporting  step  5  (Plan,  Integrate,  and  Test  the  Federation). 

•  Federation  Execution  and  Evaluation  Document,  this  document  provides  details  for  FEDEP  step 
6  (Execute  Federation  and  Analyse  results).  The  document  also  details  hardware  and  network 
requirements  and  organisational  aspects  (e.g.  machines,  network  port  numbers,  script  and  required 
staff  list  for  rehearsals  and  executions,  list  of  invited  guests). 

Inconsistencies  in  co-ordinate  conversion  algorithms  used  by  different  Federates  often  pose  an  additional 
problem.  But  in  our  case,  the  terrain  databases  used  by  constructive  Federate  (Bridge)  on  one  hand  and  the 
C2WS  Federate  on  the  other  hand,  were  identical  and  thus  correlated.  Only  the  usual  conversion  from 
map-co-ordinates  to  UTM,  used  in  our  FOM  (and  vice-versa),  was  called  for. 


8.0  RESULTS 

The  prototype  demonstrator  for  the  C2WS  with  DSS  tool  is  capable  of  transferring  a  COP  to  the  DSS  tool. 
The  user  can  try  out  several  courses  of  action  and  transfer  the  resulting  situation  back  to  the  C2WS  as  a 
planning  overlay.  The  gateway  handles  a  limited  set  of  units  and  other  C2  items,  which  shall  be  extended 
in  further  versions  of  the  demonstrator. 

Due  to  the  early  stage  of  the  development  of  the  C2WS,  some  cumbersome  precautions  have  to  be 
taken  when  demonstrating  the  simulation  functionality.  The  updates  of  the  COP  from  the  C2WS  are 
incremental,  so  only  changes  are  broadcast  to  other  stations.  A  full  COP  transfer  for  when  a  new  C2WS  is 
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added  to  the  network,  or  in  our  case,  for  simulation  purposes,  has  not  yet  been  implemented  in  the  current 
version. 

Concentrating  on  coupling  this  RNLA  C2  system  with  a  simulation  component  in  such  an  early  stage  of 
its  development  has  resulted  in  encouraging  insights  in  the  possible  additional  functionality  required  of  the 
C2WS. 

9.0  CONCLUSIONS 

The  demonstration  of  coupling  a  C2  system  to  a  simulation  tool  using  HLA  is  expected  to  achieve  its 
overall  objectives  and  received  positive  reactions  from  its  audience.  Some  lessons  learned  so  far  from  the 
project  are: 

•  Use  a  single  (authoritative)  source  for  common  data  like  terrain  data,  co-ordinate  conversion 
algorithms,  equipment  and  weapon  parameters,  etc.; 

•  Peruse  for  a  standardised  C2-Simulation  Datamodel,  represented  in  FOM  format. 

In  addition  to  full  compliance  with  HLA,  the  innovative  architectural  concept  that  was  developed  supports 
the  key  capabilities  required  for  future  C2-Simulation  interoperability  applications: 

•  An  abstraction  layer  (or  TNO-RCI  middleware)  and  a  code  generator  hiding  complexities  of  the 
underlying  interoperability  standards  and  enabling  simulation  protocol  migration  with  minimal 
changes  to  the  functional  implementation. 

•  A  structured  development  process  (the  FEDEP),  supported  by  appropriate  tools,  enabling 
migration  of  legacy  simulations  and  COTS  products  to  the  new  standard  architecture; 

•  One  single  standard  for  all  information  exchange  between  systems  is  a  solution  that  is  unlikely  to 
be  ever  achieved,  even  if  we  restrict  the  ‘universe’  to  NATO  C4I  systems.  The  Gateway  approach 
is  therefore  the  optimal  solution  to  allow  interoperability  between  the  different  worlds  that  C2  and 
Simulation  are  today. 

The  (completion  of  the)  design  and  the  development  of  the  C2WS  falls  outside  the  scope  of  our  project. 
However,  we  do  believe  that  future  C2  systems  will  include  the  design  requirement  for  interoperability 
with  Simulations  and  the  results  of  our  project  will  therefore  influence  the  development  direction  of  the 
C2WS.  The  C2WS  is  on  its  way  to  become  a  useful  and  exciting  new  C2  system,  reaching  out  to  the 
useful  and  exiting  new  simulation  standard  HLA. 
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•  The  RN  LA  C2  Workstation 
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•  Bridging  the  gap 
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Linking  C2  and  Simulation 

•  Applications 

•  Assessment  of  C2  systems 

•  Training  and  assessment  of  C2  operators 

•  Operational  decision  support 

•  Interoperability 

•  Systems  working  together 

•  Information  interoperability 

•  Standardisation 


C2-Simulation  Project  Objectives 

•  Interoperability  Architecture 

•  Staff-level  Demonstrator 

•  Team-level  Demonstrator  (BMS) 

•  Roadmap  for  future  developments 


C2-Sim  Interoperability 


High  Level  Architecture 

•  Since  1995  promoted  by  the  US  DoD 

•  NATO  M&S  masterplan  (1998) 

•  RNLA  M&S  policy  (2000) 

•  Simulation  Reuse  and  Interoperability 

•  HLA  rules 

•  Interface  specification 

•  Federation  Object  Model 

•  Run-Time  Infrastructure 

•  Runtime  Communication  Infrastructure 


The  High  Level  Architecture  (HLA) 


Run  Time  Infrastructure  (RTI) 
(Data  exchange  services) 

Federation  management  Declaration  management 

Object  management  Ownership  management 

Time  management  Data  distribution  management 


Staff-level  demonstrator 


•  User  requirements  (RNLA) 

•  Decision  support 

•  COA  analysis 

•  Route  Planning 

•  Personnel  reduction  at  CAX 

•  Concept  Demonstrator 

•  Course  of  action  analysis 

•  No  heavy  duty  wargame 

•  Choice  of  DSS  tool  ‘Bridge’ 


OllcsAfps 


C2WS  (prototype  2001) 
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•  Developed  in-house  at  the  RNLA 

•  Configurable  application  platform 

•  C2  framework 

•  C3I  architecture 

•  C2 XML 

•  Interoperability  through  a  Commercial  Of  The  Shelf 
publish/subscribe  service  (Tibco) 


Bridge  (demonstrator  DSS  tool) 
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Bridge 

•  Bridge  constructive  combat  simulation  model 

•  In-house  TNO-FEL  developed  as  demonstrator 

•  Evaluation  of  orders  ( for  educational  purposes) 

•  More  easily  manageable 

•  Custom  HLA  interface  developed 


C2WS-Bridge  Federation 


Bridging  the  gap 

•  Units  and  Obstacles  import  and  export 

•  Mapping  of  attributes 

•  Map-exchange  and  coordinates 

•  Reuse  of  components 


C2WS-Bridge  Gateway 


C2WS  Gateway  Simulation 

Presentation  (data-in-shared-memory)  DSStOOl 

services  Protocol-translation  "Bridge" 

Business  C2-XML  TNO-FEL  HLA 

services  parsing  RCI  adaptor 


Data  Tibco  HLA  HLA 

services  Rendezvous  RTI  RTI 


C2- network 


Simulation- network 


Results  and  conclusions 


•  Prototype  developed  for  conceptual  research 

•  Straightforward  architecture 

•  Useful  aid  for  customer  negotiations 

•  Future  plans 

•  User  feedback 

•  Extension  of  prototype 

•  More  generic  approach 

•  Assessment  of  C2  Workstation 

•  Training  of  C2  Workstation  users 


C2 COBP 


•  Early  interacting  with  the  customer,  the  RNLA, 
trying  to  get  to  the  ‘REAL  question’ 

•  C2-Simulation  interoperability  needs  a  Masterplan 

•  System  Architecture 

•  Datamodels 
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